ソフトウェアアーキテクチャの基礎輪読会 22章

日付：2023/12/04

章：22章 効果的なチームにする

要約

チームの生産性を高めることがソフトウェアアーキテクトの仕事

卓越したソフトウェアアーキテクトと他のソフトウェアアーキテクトの違いの1つは、チームの生産性をたかめられるかどうか

22.1 チーム境界

どれぐらい開発者に制約を課すか

これがきつすぎると

システムを効果的に実装するために必要な多くのツール、ライブラリ、プラクティスへのアクセスを妨げる。

開発者はより幸せで健全な環境を求めてプロジェクトを離れていく

これがゆるすぎると

重要なアーキテクチャ決定をすべて開発チームに任せてしまうことになる。

適切なレベルのガイダンスなしに概念検証をしたり、設計上の決定を巡って争ったりしたり、その結果、生産性の低下や混乱、フラストレーションを招くことになる。

チームに適切なレベルのガイダンスや制約を提供することで、チームが適切なツールやライブラリを使用してアーキテクチャを効果的に実装できる。

22.2 アーキテクトのパーソナリティ

22.2.1 コントロールフリークアーキテクト

ソフトウェア開発プロセスのあらゆる詳細な側面をコントロールしようとする

サードパーティライブラリを使わせず、ゼロから書くよう要求する

命名規則やクラス設計に厳しい制限を設ける

具体度が高い

開発チーム向けに擬似コードを書く

本質的にコントロールフリークアーキテクトは、開発者からプログラミングの技術を奪う振る舞いをする。それは結果的に、フラストレーションやアーキテクトに対する敬意の欠如をチームにもたらすことになる。

22.2.2 アームチェアアーキテクト

長い間コーディングをしていないタイプのアーキテクト。

開発チームから切り離されていて、初期のアーキテクチャ図が完成するとプロジェクトからプロジェクトへと移動する

抽象度が高い(図22−4)

アームチェアアーキテクトかどうかの指標

ビジネスとドメイン、ビジネス上の問題、使用する技術を十分に理解していない

ソフトウェアを実際に開発した経験が十分にない

アーキテクチャソリューションの実装に伴う影響を考慮していない

プロジェクトや開発チームの間でほそぼそと活動しているうちに、開発チームとの距離が空いてしまい、技術やビジネスドメインに疎くなってしまって「たまたま」アームチェアアーキテクトになってしまうこともある。

22.2.3 効果的なアーキテクト

適切な制約やガイドラインを提供

コントロールフリークアーキテクトもアームチェアアーキテクトも、両極だと良くないが、チームによってどちらかに "寄せる" ことは効果的で、その基準が次に書かれている。

22.3 どうやって管理する？

効果的なソフトウェアアーキテクトは、開発チームをどの程度コントロールするかわかっている。

エラスティックリーダーシップ

サバイバルフェーズでは大きいコントロール、自己組織化フェーズでは小さいコントロール

訳注: チームが「サバイバルフェーズ」、「学習フェーズ」、「自己組織化フェーズ」のどのフェーズにいるかに沿って、取るべきリーダーシップのスタイルを変えていくことで、チームを適切にガイドしていくリーダーシップモデル。

どの程度コントロールするか知るための5つの要因

チームの親しさ

チームメンバーが親しいならチームメンバーは自己組織化し始め、コントロールの必要性が低くなる。親しくないならチームメンバー間のコラボレーションを促進し、チーム内部の派閥を減らす必要があるために、コントロールが必要になる。

チームサイズ

チームが大きいならコントロールが必要で、小さいほどコントロールは必要ない。

全体的な経験

ジュニアメンバーが多いチームならコントロールが必要で、シニアメンバーが多いチームならコントロールはあまり必要ない

プロジェクトの複雑さ

複雑ならチームのためにより多くの時間を割き、単純なら簡単なのであまりコントロールは必要ない

プロジェクトの時間

長期ならコントロールが必要で、短期ならあまり必要ない。

短期なら開発チームが緊迫感を持っているため、アームチェアアーキテクトとして振る舞う方が良い。

プロジェクトの期間は短期（2か月）だろうか。それとも長期（2年）だろうか。もしくは平均的な期間（6か月）だろうか。

図22-6~図22-8参照

図は同じ比重にしているが、いくつかの要素(例えば、チーム全体の経験)は、他の要素よりも比重が思いかもしれないので、特定のシナリオや条件に合わせて、メトリクスに重み付けをする。

ソフトウェアアーキテクトがチームに与えるコントロールと関与の程度はこれらの5つの要因を考慮に入れることで判断できる。

22.4 チームの警告サイン

サービスやアプリを作るにあたって、最も効果的な開発チームの規模を考える。

以下の3つの要素が関わってくる。

プロセスロス

グループの潜在能力(チームの皆の集合的な努力) > 実際の生産性

この差がプロセスロス

チームが大きくなるほどプロセスロスは大きくなる

例.) コンフリクト

多元的無知

内心では否定していることに対して、自分が何かを見落としているのだろうと考え、全員が同意してしまう現象。

会議である案通っちゃいそうだけどあのバグがある気がするな、でもみんなが賛成してるしあのバグがあるなんて言ったら馬鹿にされちゃうかな？本当は起きないのかな？と不安になる。言わないでおこう。

責任の分散

チームの規模が大きくなるとコミュニケーションに悪影響を及ぼす

自分がサポートしなくても誰かがするだろう

この仕事は何のためにしているのかわからない

22.5 チェックリストの活用

手順はチェックリストに含めるべきではない。

含めるべきは

手順や依存タスクがないプロセス

エラーが発生しやすいプロセス

見落としや省略が多いステップがあるプロセス

できるだけ小さなチェックリストを作成すべき

チェックリストを増やすと開発者はチェックしたふりをするから

最も効果的だと感じた3つの主要なチェックリスト

22.5.1 開発者のコード完成チェックリスト

全部チェックがついていればコードが完成したと主張できるリスト。

lintとかプロジェクト固有のタスクとか

CIでできるものはするとよさげ

22.5.2 ユニットテストと機能テストのためのチェックリスト

ソフトウェア開発者がテストに忘れがちな、珍しいテストやエッジケースのテストが含まれる。

自動テストとして記述できる項目はチェックリストから削除する。

このリストは一般的なテストシナリオや特定のテストシナリオが含まれているかを確認する方法を提供するため、どのぐらいユニットテストを書けば良いのかわからない開発者への基準にもなる。

22.5.3 ソフトウェアリリースのためのチェックリスト

サーバーや外部設定サーバーの設定変更

プロジェクトに追加されたサードパーティのライブラリ（JAR、DLLなど）

データベースの更新と対応するデータベース移行スクリプト

など

リリースがちゃんと行われて、問題の再発を防ぐためのチェックリスト

22.6 ガイダンスの提供

様々なライブラリについて自分たちで判断できるか、どのライブラリがOKでどれがNGなのか

効果的なソフトウェアアーキテクトは、次の質問に答えてもらうことで、開発チームにガイダンスを提供できる。

提案されたライブラリとシステム内の既存機能との間に重複はあるか？

既存ライブラリを確認することを開発者に促す

ライブラリはどんな根拠に基づいて提案されているか？

技術的な根拠とビジネス上の根拠の両方を要求する。

開発チームが決定できることとできないこと(図22-13 参照)

特別な目的のもの（なんだろ)：開発者の承認で入れる

汎用的な目的のもの（Kotlinx.serializationとか）：アーキテクトの承認による

フレームワーク (Jetpack Compose）：アーキテクトの決定による

まとめ

効果的なチームを作るためには

チームをどの程度コントロールするか判断する

エラスティックリーダーシップを用いる

チェックリストの活用

設計指針の効果的な伝達による適切なガイダンスの提供

応用

code:sample.kt

質疑応答